A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.
The present invention is directed to computer software compiler technology and more particularly to a computer compiler that has the capability of inserting in assembly or object code additional code that permits real time scaling, faulting and modulation of variables without having to modify associated source code.
Software development is characterized by a process involving the steps of writing and editing a program, compiling and linking the program and running the program. A compiler translates a source program that has been written in a high-level language such as FORTRAN, PASCAL or C/C++ into a machine executable form known as an object program. Improvements in compiler technology are typically associated with optimizing the object code that is generated so that at run-time, the program runs as efficiently, and thus as quickly, as possible. Examples of such compiler improvements can be found, for example, in U.S. Pat. No. 5,313,387 to McKeeman et al. and U.S. Pat. No. 5,335,344 to Hastings. However, speed and efficiency are not necessarily the only improvements available in a compiler or compilation process. Improved functionality, even in exchange for efficiency, is sometimes desired.
High level languages such as FORTRAN have been in existence for 30 years or more. Despite their age, these languages continue to be used. In fact, FORTRAN source code that was written decades ago might still be used by present day software engineers even though these engineers have no knowledge of the substance and character of that source code. These software engineers rely on the fact that the source code, when compiled, provides the expected functionality. The present inventor has experienced this phenomenon with respect to simulation software used to design, build and control controllers for power generation equipment, wherein at least a portion of the simulation software source code relied upon was written years ago, but is nevertheless still used as it represents a fully developed and reliable portion of an overall program. It is believed that design and software engineers in other technological fields have similar experiences with older source code blocks.
While reliance on old source code is advantageous due to its reliability, etc., there is a disadvantage to its use in that, should it be desirable to modify the older source code to provide a somewhat different functionality, that is, to control the output thereof, such a modification could unexpectedly modify the overall program in an unintended and difficult-to-recognize way. Indeed, it is common for software engineers to leave older source code in its original form so as not to overly complicate software development.
Nevertheless, there are times when it is highly desirable to control the output of portions of a program that rely on older, unfamiliar source code. For example, in order to test newly written source code, it is helpful if the variables being output from the older source code and used as input to newly written code blocks can be modified to analyze, for example, boundary conditions or particular values of interest, such as a fault value, in the newly written portions of the program. However, it is generally ill-advised to modify the older source code directly in fear of interjecting software xe2x80x9cbugsxe2x80x9d that likely will be difficult to correct in view of the low level of familiarity with the older source code. Moreover, modification of the older source code results in multiple revisions being available to other software engineers, which leads to configuration management difficulties.
There are known methods by which variables of a computer program can be modified. Specifically, simulation languages such as Boeing""s EASY5(trademark), Simulink(trademark) and similar programs provide means for intercepting variables 104 as they flow, in a conventional manner, from an upstream code block 100 to a downstream code block 110 (FIG. 1). As shown in FIG. 2, this xe2x80x9cinterceptingxe2x80x9d capability usually means stopping the simulation, inserting user defined variable modification code 106, recompiling the changed code, and running the simulation with the new capability, i.e., modified variables 104a. This process is time consuming, prone to errors where a large number of variable connections exist, and generally results in larger and more complex (less easy to understand) code. It also dictates that FORTRAN legacy code, for example, must be changed repetitively, introducing revision control and simulation model accuracy difficulties. As used herein, xe2x80x9clegacy codexe2x80x9d refers to the older, less familiar source code.
Also known are source code modification and compilation-based techniques for introducing variable scaling capabilities, such as the aforementioned code insertions and the employment of user defined variable spaces, as shown in FIG. 3, here in xe2x80x98Cxe2x80x99 language notation, where user-written routines access information stored about program variables including, for example, gain and offset, and perform the desired scaling. A fault value can also be accessed depending on the value of the xe2x80x9cswitchxe2x80x9d variable. However, this technique results in yet another layer of source abstraction that may conflict with existing simulation programs (e.g., EASY5(trademark), Simulink(trademark), etc.). Indeed, these compilation-based techniques typically require (a) manual creation of user code that is aware of the address, data type and name of the variables in the so-called legacy code, (b) modification of the legacy source code to intercept all assignment references, e.g. intercepting A=B and replacing the same with A=B*GAIN +OFFSET, to scale internal variables, and (c) explicit linking with the object code produced from the legacy source code.
Thus, the above and the aforementioned variable control schemes do not solve the problem of user definition and addition of scaling capabilities for variables without source code modifications.
Thus, there is a need to provide access to and manipulation of variables during run time of an executable program produced from, for example, FORTRAN source code, without modification of the same FORTRAN source code. More specifically, there is a need to provide this functionality without the additional source code modification 106 shown in FIG. 2, or the creation of user-defined variable space followed by source modification as shown in FIG. 3.
Hereinafter reference is made to the FORTRAN programming language and compilers therefor, but it is to be understood by those skilled in the art that the method and apparatus described herein is applicable to any software programming language compiler.
In accordance with a preferred embodiment, the functionality of a FORTRAN compiler is extended to achieve real time variable manipulation. More particularly, disclosed is an improved compiler that takes normal variable move and assignment operations and adds assembly language, and ultimately, object code, that allows real time scaling, faulting, and modulation of FORTRAN variables without the modification of FORTRAN legacy (well-established, revision controlled) source code. The application of the functionality of the improved compiler is preferably controlled by the user, and when the particular functionality is not desired, the compiler preferably reverts to normal interpretations of the FORTRAN language. This control is preferably effected via a software switch. Such a capability is particularly useful for real time simulation process monitoring, tuning, I/O scaling and fault generation since variables can be manipulated without having to change source code or having to recompile with scaling parameters in changed source code. Such monitoring, tuning, scaling and like functions are particularly useful with FORTRAN-based simulation programs such as Boeing""s EASY5(trademark).
When the functionality of the preferred embodiment of the compiler is activated and if a variable is specified in one of at least a compiler switch command line, in an auxiliary file, a language extension/compiler directive, or a compiler switch modifier indicating xe2x80x9callxe2x80x9d variables, the preferred embodiment:
(1) treats each variable normally in the parse of the FORTRAN source, but allocates additional space for variable modification parameters, such as a xe2x80x9cfault_valuexe2x80x9d (i.e., a value to insert rather than the upstream, or left hand side) variable, a xe2x80x9cgain,xe2x80x9d an xe2x80x9coffset,xe2x80x9d and a multi-position xe2x80x9cswitchxe2x80x9d to control the use of fault_value, gain, and/or offset parameters;
(2) during compilation, inserts assembly code (or object code) to apply the fault_value, gain, offset, and switch to a variable, thus not altering the FORTRAN source code, yet providing the capability for real time variable modification in the resulting executable; and
(3) provides means for initializing, storing and accessing the fault_value, gain, offset, and switch variables at run time.
The advantages of the preferred embodiment include:
No FORTRAN source code changes;
No complications/additions to legacy FORTRAN;
Elimination of user-defined scaling implementations, rework, and the like;
Capability is transparent to the user, and easily selectable with a compiler switch;
Capability is intrinsic in the compilation process, no user code needs to be generated; and
Intrinsically supplies I/O points with scaling/faulting capabilities.